1. Field of the Invention
This invention relates to a network of computer systems, including but not limited to the Internet environment, and more specifically for securely printing a file retrieved from a separate file source in the network environment.
2. Description of the Related Art
A network environment can comprise an endless number of configurations, including but not limited to computer systems communicatively connected to the Internet, to a wide area network, to a local area network, using TCP/IP connections, using token ring connections, etc. Likewise, the computer systems themselves may vary from network terminals with minimal storage and CPU processing functionality to personal computers, including laptop computers to workstations to servers to mainframes. The relationship among the computers can vary, e.g., as being independent from each other, or having distributed relationships, or having client/server relationships, etc. Some or all of the files may be stored in a dedicated file storage system, e.g., a file server, database management system, etc., or within the storage of each system. Likewise, printers may be attached to any or all of the systems and/or there may be print servers to which the computer systems can be communicatively linked.
There are many different types of security issues that arise in a network environment. Some files must be encrypted at the sending end and decrypted at the receiving end to ensure that the file contents are not intercepted by an unauthorized entity during the transmission. This security feature, along with other security features that are known, can guarantee that a file has not been tampered with or can ensure the identity of the sender or receiver. Some of these security features are further discussed below.
Cryptography
Conventional cryptography, or in other words traditional symmetric cryptography, is used to maintain the privacy of the information contents. Conventional cryptography requires that the sender and receiver of an encrypted message share the same secret key. The same key is used to both scramble (encrypt) and unscramble (decrypt) information. In 1977, the National Bureau of Standards approved a block cipher algorithm referred to as the Data Encryption Standard (DES). Binary-coded data is protected by using the DES algorithm in conjunction with a key. An authorized user must have the key that was used to encipher the data in order to decipher it. Unauthorized recipients of the ciphered information content who may know the DES algorithm but who do not know the key cannot decipher the information content.
The major problem with this method is guaranteeing that both sender and receiver have the key, but no one else does. Sharing the key requires that one party send it to the other. However, since most communication networks cannot be trusted, the key itself must be encrypted. If it is sent in the clear, there is a danger that someone eavesdropping on the line could get the key and then be able to decode messages sent between the two parties. Others have sent the key via registered mail, which slows the communication process down, and begs the question of why not just send the message registered mail if time is not of the essence.
As described above, to protect the information content from unauthorized recipients, the key has to be kept secure from unauthorized users. Thus, the security of the contents depends upon the security of the key. As such, the key has to be distributed to authorized users in a secure manner.
Public Key Cryptography
Public key cryptography was first introduced by Whitfield Diffie and Martin Hellman of Standford University in 1976. It not only can be used to ensure the privacy of transmitted messages, but it can also be used in other applications, including digital signatures.
For ensuring the privacy of transmitted messages, public key cryptography does solve many of the problems, discussed above, of securely distributing the key used in conventional cryptography. Public key cryptography is based on two keys, a private key and a public key, that work together. A person""s public key is openly made available to others, while their private key is kept secret. One key is used for ciphering and the other key is used to decipher information content. For each encryption key there is a corresponding, but separate and distinct, decryption key. Messages encrypted with a person""s public key can only be decrypted with that person""s private key. Even if one key is known, it is not feasible to compute the other key.
In a public key system, it is possible to communicate privately without transmitting any secret key. For example, the encryption key for each user is made public by being distributed or published. Anyone desiring to communicate in private with a recipient merely encrypts the message under the recipient""s public key. Only the recipient, who retains the secret decrypting key, is able to decipher the transmitted message.
A combination of conventional cryptography and public key cryptography allows a secret key to be sent securely to an intended recipient. The sender encrypts a message with the secret key using the recipient""s public key. The recipient then uses the recipient""s private key to decrypt the message and to get the secret key for other transmissions. Since public key encryption is slower than secret key encryption, this approach allows subsequent transmissions to use the faster conventional secret key cryptography approach.
Digital Signatures
In these cryptographic systems, there is sometimes still a need to verify that the sender of a received message is actually the person named in the message. Digital signatures, which are based on public key cryptography, are used as a means to authenticate the sender of a message. A digital signature allows a digital message to be signed so that any receiver of a digitally-signed electronic message can authenticate the sender of the message and verify the integrity of the signed message. That is, the recipient is assured that the message is received as sent, and that it is not a forgery.
To ensure that the original true sender sent the message, a process just the opposite of the one used to ensure a private communication using public key cryptography described above is used. For example, a user who has made public a public key can digitally sign a message by encrypting the message, or a hash of it, with the user""s private key before transmitting the message. Recipients of the message can verify the message or signature by decrypting it with the sender""s public encryption key. This process is just the opposite of conventional cryptography in that the message is first encrypted by the sender using the sender""s private key, and decrypted by the recipient using the sender""s public key. Anyone who has the sender""s public encryption key can read the message or signature. Any such recipient is assured of the authentication of the creator of the message since only the sender having the secret private key could have created the message or signature. The recipient is also assured that the message has not been altered since it was first created and the digital signature was attached to it. Any recipient can authenticate the signature and verify the integrity of the message by using only the signer""s public key.
In the above example, the digital signature was the encryption, using the sender""s private key, of the message itself. In the Digital Signature Standard (ANSI X9.30 Part I), a person""s digital signature is a fixed-length string of bits that are attached to an electronic message of any length. To create a fixed-length digital signature, a hashing function is used that converts a message of any length to the same fixed-length hash, or digest, of the message. The Secure Hash Algorithm (SHA) is a known hash function that is part of the Digital Signature Standard. This hash of a message is like a xe2x80x9cfingerprintxe2x80x9d in that it is practically impossible for two distinct messages to result in identical hashes. After creating a hash of the message, the sender""s private key is applied to the hash to create the digital signature for the message. The digital signature is a function of both the message being signed and the signer""s private key. As long as the private key is kept secret, the digital signature cannot be created by anyone else.
Upon receipt of the digitally-signed message, the recipient uses the sender""s public key to convert the digital signature to the hash that the sender computed. Next, the recipient applies the same hash function to the plain text message received and gets the hash of the received message. If the hash of the received message is identical to the hash obtained by using the sender""s public key to convert the digital signature, then the recipient has authenticated the sender""s digital signature and verified the integrity of the signed message.
Certificates
The identity of the signer can only be guaranteed to the extent that the receiver is assured that the public key actually belonged to the purported sender. One known technique for addressing this problem is to rely on some trusted authority, e.g., a government agency, to ensure that each public key is associated with the person claiming to be the owner. The trusted authority would create a digital message, known as a certificate, which contains the claimant""s public key and the name of the claimant. A representative of the authority would sign the digital message with the authority""s own digital signature. The authority""s digital signature would be created by using the authority""s private key, and it would be deciphered by recipients using a public key of the authority which has been widely disseminated and made available such as through telephone books, newspapers, and/or on an Internet web page. This certificate is sent along with the sender""s message and the sender""s digital signature. The recipient uses the authority""s public key to decipher the certificate and find the sender""s authentic and certified public key. The recipient then uses the sender""s certified public key to verify the sender""s signed message. Thus, the certificate can be easily authenticated and the message integrity verified.
Access Control Using Certificates
Typically, access to resources of a computer system (xe2x80x9cserverxe2x80x9d) from another system or user (xe2x80x9cuserxe2x80x9d) has been controlled through passwords. This requires the server to maintain a database of all authorized users and each user""s password. However, if a user shares the password with another unauthorized user, the integrity of the password access control system is diminished.
In a certificate-based access control system, the server only needs to authenticate certificates issued by a certification authority. The server does not need to maintain a database about users or each user""s corresponding password. To gain access to resources of the server, the user submits the user""s certificate. From the certificate, which contains data that cannot be forged, the server can obtain the user""s authenticated public number, personal data, and access privileges. The server can then transmit to the user a random message that the user must digitally sign with the user""s private number and return it to the server. The server can then authenticate the digital signature using the public number in the certificate and check that the signed message is the same it sent to the user. With this digitally-signed response, the server can determine if the user has the correct private number corresponding to the authenticated public number in the certificate.
Secured Transmissions Between a Sender and Receiver
The above-described secure transmission techniques are best applied in situations where the messages and/or files are transmitted directly between the sender and the intended user.
In any network environment, situations may arise where a user (an individual interacting with a system via a terminal or an application running on a system) desires to print a document that is located remote from the user. The document may be protected from being accessed by anyone other than those users that have access privileges.
Typically, a user will request the document from the remote system, the remote system will verify that the user has the correct access privileges, and if so, then the remote system will send a copy of the document to the user. The user will then send the file to a printer for printing. However, such a user having access privilege may desire to print the document on a remote printer or print server but does not desire to first retrieve and store the document at the user""s own local computer system (referred to for convenience as the client system). For various reasons, a user may not wish to have the document resident on the user""s own machine. Some of these reasons may involve, for example, any one or more of the following: the client system may not be in a secure environment; there may be network traffic considerations; or the client system may not have the storage space for receiving the file, etc. In addition, the file server may not want a copy of the file to be stored on the client system. The owner of the file (e.g., document) may wish to control the number of copies being distributed, e.g., to protect copyright in the document and/or payment of a fee on a per-copy basis. If a copy were resident on the client machine, illegal copies could be further made from that copy, or illegal changes could be made to the document. Instead, it may be more desirable if the printer could get the document directly from wherever it may be stored and print the document.
However, in order to do this, the printer would need to have the same access privileges as the user had if the document was access protected.
There is a need to allow a print server to get a print file from a third party identified in an original request so that the document can be printed without first obtaining the file by a client system originally requesting the print file. However, when the print server gets the file, the third party must be guaranteed that the request is valid (i.e., the print server has been authorized to get the file, and the original client can legally print the document). Such a scenario is not known to be possible under existing protocols.
It is therefore an object of this invention to allow a printer to retrieve a file directly from a file source upon a request from a client based upon an authorization from the file source to the client.
It is therefore a further object of this invention to provide a printer with the same access privileges as a user that is requesting a xe2x80x9cprint by referencexe2x80x9d printing operation.
The term xe2x80x9cprint by referencexe2x80x9d is used herein for a printing scenario where the user does not actually retrieve the document and store the document in the user""s own local computer for use as the target copy of the document for printing.
The system, method, and program of this invention enables a user, i.e., client system, to pass authorization to a printer to retrieve and print a file from a file source. The scenario is analogous to an agent requesting tickets to an event for the agent""s principal. The agent gives the principal""s name to the ticketing office and receives back an order number. The agent gives the order number to the principal. The principal then goes to the xe2x80x9cwill-callxe2x80x9d window of the ticket office at the time of the event, and presents the order number and the principal""s ID to the ticketing office to receive the tickets. The ticketing office knows the principal is who he purports to be by his ID, such as a driver""s license which is issued by a trusted authority, i.e., the government; and knows that the principal is the one to give the tickets to because the agent identified him in the initial request, and the principal presented the order number that corresponded correctly to that initial request.
In a network printing environment, when the client requests to have a document printed, the document source (file source) issues a xe2x80x9cwill-callxe2x80x9d certificate to the client. A xe2x80x9cwill-callxe2x80x9d certificate guarantees the authorization to have the document accessed and is capable of being passed to a third party, i.e., a print server. The will-call certificate is created by the file source and its contents are based upon the initial user request to the file source. The certificate provides the information needed by the print server to request the print data, such as the distinguished name of the place where the document is stored and the path to the file which contains the document. The will-call certificate also contains information for the file source to verify that any such will-call certificate presented to the file source by a printer is legitimate. For instance, the will-call certificate contains a digital signature of the file source. The digital signature can be a unique signature for that specific request (making it similar to an order number in the above analogy) by using a hashing function on the other contents of the will-call certificate. The digital signature is created using a private key known only by the file source. The will-call certificate may also contain the printer ID and/or network address of the printer that the user specifies in the user""s initial request to the file source as the printer that will be retrieving and printing the file. The will-call certificate may also contain the user ID making the initial request.
The client sends the will call certificate to the printer along with a request to print this file. When the printer is ready to print the data, it sends a message along with the will-call certificate to the document source requesting the document. The printer""s authorization to get the document is the will-call certificate. Since the certificate contains the digital signature of the file source, it is not possible for the will-call certificate to be forged. Also, when the printer presents the will-call certificate to the file source, the file source can verify that for that digital signature of the file source contained in the will-call certificate, the printer is the printer as initially identified by the user, and the printer is at the same network address. The printer will also send to the file source, along with the will-call certificate, the printer""s digital certificate so that the file source can verify that the printer is who the printer purports to be. Such a digital certificate can be one that is configured according to copending patent application Ser. No. 08/979,505 incorporated by reference.
Other embodiments incorporating a will-call certificate may include xe2x80x9cpurchasedxe2x80x9d documents that are sent to the server in a cryptolope.